C) Remarks 



Rejections under 35 U.S.C. S1 12: 

Claim 1 2 was rejected under 35 U.S.C. §1 1 2, 112, based on an asserted indefiniteness 
arising from the meaning of the phrase "establishes . . . identification on." 

The requirement of 35 U.S.C. §112, H2, is that the claim language reasonably 
apprise those of skill in the art of the scope of the claimed invention. S3 Inc. v. nVIDIA 
Corp. , 259 F.3d 1364, 1371-72 (Fed. Cir. 2001). The terms used in the claims bear a 
presumption that they mean what they say and have the ordinary meaning that would be 
attributed to those words by persons skilled in the relevant art. See CCS Fitness, Inc. v. 
Brunswick Corp. , 288 F.3d 1 359, 1 366 (Fed. Cir. 2002). The ultimate determination is that, 
"[i]f the claims read in light of the specification reasonably apprise those skilled in the art of 
the scope of the invention, § 1 1 2 [112] demands no more/' Miles Lab., Inc. v. Shandon, Inc. , 
997 F.2d 870, 875 (Fed. Cir. 1993). 

The phrase in question concerns the requirement that the server system "establishes" 
a "user account identification " "on" the client system. The conventional dictionary meaning 
of the word "establishes" is to "make firm or stable." The conventional dictionary meaning 
of the word "on" is as a function word describing a relation of being "in specific contact 
with." Thus, the claim limitation requires an identification of the user account be made firm 
in specific relation to the client system. 

Support for this limitation is provided by the present specification in describing the use 
of a cookie placed on the client system. As conventionally understood, the cookie contains 
sufficient encoded information to allow a user account to be identified by the server system 
when the relevant contents of the cookie are presented to the server system. 

The claim is, of course, not limited to the best mode described in the specification and 
is not limited solely to the literal interpretation of the claim words. The functional 
requirement defined by the claim wording - that the user account identification be 
established as a specific relation to the client system - is unquestionably clear and definite 
to a person of ordinary skill in the relevant' art. Therefore, the claim wording, as presently 
presented, fully complies with the requirements of 35 U.S.C. §112, U2. 

Reconsideration of the rejection of Claim 12 under 35 U.S.C. §1 12, U2 is respectfully 
requested. 

Rejections under 35 U.S.C. SI 03: 

The currently pending claims, Claims 8 and 12, stand rejected under 35 U.S.C. 
§1 03(a) as obvious in view of Markus (US Patent 6,490,601). 
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Through the prior Responses, Applicants have established that the system primarily 
described in Markus requires the execution of specialized shippable code program on the 
client in order to implement Web-form completion. Markus also briefly describes a 
"transactor" system in the background section of the reference. A Web address for the 
Transactor company is given, but is not active. A Web search for the company or further 
information yielded no relevant results. 

The Action asserts a combination of Markus - that is, the primary system described 
in Markus - and the transactor system as establishing the obviousness of the presently 
pending claims^ Specifically, the Action acknowledges that Markus requires the download 
and execution of executable code, but advances the transactor system as teaching that "the 
user receives only user information." In essence, the assertion is that no executable code is 
provided by the transactor server to complete a Web-form with the user information retrieved 
from the transactor server. 

With respect, the assertion of obviousness must fail for at least the following 
reasons: 

1) the transactor disclosure is not enabling; 

2) the combination of references fail to teach or suggest the claimed 

invention; and 

3) there exists no relevant motivation to modify. 

The Disclosure of the Transactor System Is Not Enabling 

The interpretation of the transactor system provided by the Action is that the 
transactor server provides only user information such that "the user receives only user 
information." This interpretation is based on the cited statement in Markus that "the user is 
not required to download or install any software onto his or her computer (Col 3, II 38-44)." 
This statement is made, however, in distinguishing the transactor system from another prior 
art system where a user is required to independently download and install "wallet" software. 
Consequently, the cited statement is not dispositive that no executable code is downloaded 
from a transactor server. 

If the cited statement is true in the manner asserted by the Action, then the statement 
is inconsistent with the further description of the transactor system as presented at Col 4, 
II 1-16. The transactor system is described there as a process where retrieved user 
information is received into a first browser window, initially stared by invoking a bookmarked 
link. When user data is retrieved, a communications channel is established between the first 
window and a second window containing a Web-form. Finally, an "automated fill" is 
performed to populate the retrieved user information into the form. Markus further describes 
this cross-communications between windows as "known in the art to compromise user 
security." (Col 4, II 36-37). 
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To a person of ordinary skill in the relevant art, the transactor process as described 
in Markus would sound like a description of an applet-managed data transfer process. 
Conventional browsers are not known to perform cross-window communications in the 
absence of some third-party provided control program. Applets are well-known to be able 
to provide the type of processing functions attributed in Markus to the transactor process. 
An applet can be downloaded and executed transparent to a user based only on the user 
acting to open a Web page. Furthermore, the applet sandbox security model does not by 
default allow cross-windows communications specifically to prevent an applet in one window 
from reading or modifying potentially sensitive user data in another window. 

A fully consistent and, moreover, the most reasonable interpretation of the transactor 
description is that an applet is in fact used to implement the disclosed process. The applet 
would be automatically downloaded to and executed on the client system when the first 
window is opened. The applet retrieves requested user information from the transactor 
server and then parses and populates the user information cross-windows into the Web- 
form. 

Conversely, if, as asserted in the Action, an applet or equivalent client executed 
program is not used, a person of ordinary skill in the art would simply have no idea of how 
to implement the transactor process. Markus provides no description of a better or even 
alternate implementation that could possible perform the described transactor process. Only 
delivering user information to the client system, as the Action asserts, inherently falls short 
populating the delivered user information into any form fields. 

Given that the description of the transactor process fails to enable anyone to 
functionally understand or use the transactor process, that description is not available as a 
reference against the presently pending claims. (A printed publication is not citable prior art 
if the provided disclosure is not enabling. In re Donohue , 766 F.2d 531, 226 USPQ 619 
(Fed. Cir. 1985); The disclosure in an assertedly anticipating reference must provide an 
enabling disclosure of the desired subject matter; mere naming or description of the subject 
matter is insufficient, if it cannot be produced without undue experimentation. Elan Pharm., 
Inc. v. Mayo Foundation for Medical and Education Research , 346 F.3d 1051, 1054, 68 
USPQ2d 1373, 1376 (Fed. Cir. 2003)). 

The Disclosure of the Transactor System Fails to Teach or 
Suggest the Claimed Invention 
Even if the transactor disclosure were available as a reference, the combined 
references are factually insufficient to teach or suggest the claimed invention. In holding an 
invention obvious in view of a combination of references, there must be some suggestion, 
motivation, or teaching in the prior art that would have led a person of ordinary skill in the 



Attorney Docket No.: PRPL3012 

gbr/prpl/30 12.022. resp3 .wpd 



Page 7 



art to select the references and combine them in the way that would produce the claimed 
invention . Karsten Mfa Corp. v. Cleveland Golf Co. . 242 F.3d 1376 (Fed. Cir. 2001). 



Independent Claim 8 specifies a complete system for enabling a partner site to 
efficiently request specific user information from a repository server and have that 
information returned to the partner site. In general terms to describe the context of the 
presently claimed invention, and as outlined visually in Figure 2 A of the specification, the user 
is initially presented with a Web-form from a partner site: 

- The user clicks on a Web-form button to request automatic completion. 

- The click results in a network request, bundling a detailed mapped set of "server 
datum identifications" and an account identification that is sent to the repository "computer 
system": 

... said computer system being responsive to a network request 
received from a partner site relative to a client computer system, 
wherein said network request provides said account 
identification and said server datum identifications 

- The repository "computer system" returns a specifically corresponding set of 
"partner datum identifications" and associated "datums of confidential user-information" to 
the partner site : 

... wherein said mapped relationship definition implements said 
mapped relationship in a form evaluateable by said server 
system upon receipt as part of said network request to enable 
said server system to provide a network response to said partner 
site containing the datums of confidential user-information 
corresponding to said partner datum identifications 

- The partner site may then directly use the "partner datum identifications" and 
corresponding user information or update the Web-form on the user/client computer system 
to display the completed form to the user. 

The system of Claim 8 also specifies that the repository/computer system includes a 
"mapping processor." Given that the claim specifies: 

... wherein said server datum identifications have a mapped 
relationship to the confidential user-information requirements of 
said partner site with respect to said user account, which is 
expressed as partner datum identifications 
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the "mapping processor" operates to: 

... autonomously convert server datums to partner datums 
through a process defined by said mapped relationship 
definition 

Consequently, a system implementing the present invention, as set forth in Claim 8, 
does not require the download or execution of any additional program in order to effectively 
complete a Web-form. Furthermore, the mapping utilized by the present invention achieves 
a fundamental independence from the specifics of any particular Web-form; specifically 
unlike the prior art systems, changes made to a presentation form and format of the form 
have no affect on the ability of the map to specify the specific information requested and the 
manner that the data is to be represented as delivered to the partner site. In the preferred 
embodiments, the map or a reference to a named map is retrieved from the partner site in 
response to the button click on the Web-form or included in the link invoked by the button 
click on the Web-form. 

In contrast, the transactor disclosure simply does not teach or suggest any 
implementation actually capable of eliminating the need and use of the shippable code 
program that is then executed on the client system. A person of ordinary skill in the relevant 
art, considering the transactor disclosure, would have no idea of what modifications could 
be made to eliminate the need for or use of the Markus 'shippable' code. 

Alternately, if the transactor disclosure is recognized as teaching the use of an applet 
downloaded from the transactor server, then again the combined references fail to teach or 
suggest the claim limitation any way of avoiding client executed code. 

Furthermore, the combined references objectively fail to teach or suggest the use of 
a mapped relation between server and partner datum identifications. 

The prior art also fails to teach or suggest the return of the mapped user information 
to the partner site in any event and certainly not in combination with "partner datum 
identifications/' Unlike the cited prior art, the claim presents no requirement that the 
returned, mapped user information be presented first on the user computer system before 
being forwarded to the partner site. 

Finally, the complete claimed sequence of (1) collecting the user information request 
identifiers and an account identifier in response to a user action, (2) forwarding this request 
to the repository server, and (3) returning user information data to the partner site is clearly 
not taught or suggested by the cited prior art. 
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Since, no combination of the prior art can actually produce the invention as set forth 
in Claim 8, the claims cannot be properly considered obvious. 

The Action Fails to Demonstrate any Relevant Motivation to Modify 

Given the reasonable interpretation of the transactor disclosure as teaching 
the use of an applet, the cited prior art is properly viewed by those of ordinary skill in the 
relevant art as endorsing the use of downloadable code programs. The cited prior art 
methods are not intent on eliminating the downloaded code. Instead, both methods are 
effectively aimed at simply hiding the download and execution of the executable code. 
Markus is rather explicit in teaching that a specially constructed 'shippable' executable code 
program is required to be executed on the client system to actually apply provided user 
information to the Web-form. From this perspective, a person of ordinary skill in the relevant 
art would not perceive any reason consider modifications intended to remove the 
downloaded code. 

In addition, the cited prior art effectively endorses a requirement for presenting the 
user information within the Web-form on the client computer system before the user data is 
forwarded on to the merchant/partner server. The transactor, Markus, and even "wallet" 
prior art system are evidently all consistent in completing the Web-form on the client 
computer system. There is no teaching or suggestion by any of the prior art to operate in 
any other order. 

Relevant motivation to combine would need to address at least these two fundamental 
differences between the cited prior art and the presently pending claims. 

Instead, the Action indicates that suitable motivation can be found merely in the desire 
to "reduce[] needed bandwidth for communication between the repository and the user. For 
example, this system would be optimal in situations where bandwidth is limited or 
expensive." While true in the very generic sense that faster is better, the suggested 
motivation is essentially irrelevant in the context of the claimed invention. The references 
themselves do not identify any issue or concern with the speed or bandwidth use of the 
systems described. Nor do the references identify any issues from which a specific concern 
could be inferred. Furthermore, there is no reason to believe that the applets and shippable 
code of the prior art references are of any substantively larger size relative to other 
conventionally acceptably sized applets and JavaScript programs that are frequently 
downloaded by conventional Web users. 

Consequently, persons of ordinary skill in the art would not view bandwidth usage as 
a relevant motivation to modify the structure and behavior of the cited prior art systems. 
Moreover, the suggested motivation is not of a nature that would motivate a person of 
ordinary skill to make the kinds of modifications that would be necessary to specifically 
realize the claimed invention given the prior art references teachings as a starting point. 
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The teachings of Markus, including the transactor system, fails to teach or suggest the 
complete system set forth in Claim 8. Therefore, Applicants respectfully assert that the 
present claims are patentable over Markus. Reconsideration of the rejection of Claims 8 and 
12 is requested. 

Conclusion: 

In view of the above Amendments and Remarks, Applicants respectfully assert that 
Claims 8 and 12 are now properly in condition for allowance. The Examiner is respectfully 
requested to take action consistent therewith and pass this application on to issuance. The 
Examiner is respectfully requested to contact the Applicants' Attorney, at the telephone 
number provided below, in regard to any matter that the Examiner may identify that might 
be resolved through a teleconference with the Examiner. 



Respectfully submitted, 



Date: 





Gerald B. Rosenberg 
Reg. No. 30,320 



NewTechLaw 

285 Hamilton Avenue, Suite 520 
Palo Alto, California 94301 
Telephone: 650.325.2100 
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